Add microphone selection to Settings - #163

- AudioQueueNewInput takes a capture-free closure literal forwarding to
  the static callback: a C function pointer cannot be formed from a
  static-method reference, only a top-level func or a literal closure.
- The static callback drops the unused packet timing/description
  parameters (raw LPCM never needs them), which also satisfies
  swiftlint's five-parameter limit.
- MicCapture.start(): break the warm-take/make-backend assignment the
  way swift-format asks (AddLines at the try).

Swift refuses the implicit inout-to-UnsafeRawPointer conversion for a
variable whose type carries an object reference, so the
kAudioQueueProperty_CurrentDevice value (the CFString reference itself)
goes through withUnsafeMutablePointer — the same pattern
AudioInputDevices already uses for the UID-translation qualifier, which
this CI run compiled cleanly.

Also swap the one key-path-inside-#expect in AudioInputDevicesTests for
an explicit closure, per AGENTS.md's rethrows/key-path macro trap.

Owner-directed (Alex Kroman, 2026-08-25): replace both capture backends
— the AVAudioRecorder/WAV path and the device-pinned AudioQueue — with
one AVCaptureSession recorder (CaptureSessionRecorder) behind the
existing CaptureRecorder seam. Still fresh per session: the session is
built around the press-time resolution of the selection (pinned device
via AVCaptureDevice(uniqueID:), else the default input, with the same
pure missing-device fallback), its data output converts to 16 kHz mono
16-bit LPCM, and the delegate accumulates upload-ready S16LE in memory
— no temp file, no decode pass.

Liveness gate inputs re-derived on the new API with MicLiveness itself
unchanged: the clock is the frames actually delivered (summed off each
sample buffer), power is the connection's AVCaptureAudioChannel
averagePowerLevel; fail-closed timeout, transport-keyed caps, and the
Bluetooth tail linger all still key off the resolved device's CoreAudio
snapshot. silenceFloorDB stays -115 dBFS — the dBFS math (0 = full
scale, one int16 LSB ~ -90) is meter-independent — but was calibrated
on the retired meter and must be re-verified on hardware.

Warm-up now pre-builds the session without starting it — the device
stays closed and no input indicator shows while idle — so route
activation lands inside the connecting window at record()'s
startRunning(). A built-but-idle session holds nothing open, so the
60 s warm expiry (which existed to un-pin AirPods from their degraded
output profile) is deleted along with its generation tickets.

Settled-decision prose updated consistently in AGENTS.md's table, the
project-guardrails skill, and check-invariants.sh's advice string; the
AVAudioEngine/installTap ban is unchanged and its anchors still pass
--self-test. Tests updated to the new backend (warm suite identity
probe replaces the generation counter; live suites stay env-gated).

Closes the item the previous commit deliberately left open. The transport
read was the one piece of the input path kept on CoreAudio, because
AVCaptureDevice.transportType was confirmed to report the same four-character
codes for built-in, USB, virtual and aggregate devices but *not* for
Bluetooth — and Bluetooth is the only case the policies turn on. A transport
that failed to read as `blue` would silently cost the 2.5 s liveness cap and
the 220 ms tail linger, which is the missing-last-word bug both exist to fix.

Measured with AirPods connected: AVCaptureDevice reports `blue`, so the
parallel HAL read is gone — with it the UID→AudioDeviceID translation and
AudioRoute's input half. AudioRoute is now just the default *output* device
(AVCaptureDevice describes capture devices, so AudioRouteMonitor has no
equivalent) plus the property addressing the two share.

The same session surfaced two things the wired hardware could not, both in
the live suite rather than the product:

- `record()` returns before the device is open on Bluetooth. `startRunning()`
  takes ~80 ms on AirPods and the first frame lands ~410 ms later, where on a
  USB interface `startRunning()` blocks the whole ~600 ms and frames follow
  ~8 ms behind. The gate already handles it — that is what it is for, and the
  wait's clock starting after record() returns is what keeps the caps tight —
  but the new engagement test asserted the device was open the instant record()
  returned, which is true only on transports that block. It polls now.
- The capture meter has a second not-ready value. Until AVCaptureAudioChannel's
  first update it reports -Float.greatestFiniteMagnitude (~-3.4e38), not the
  -160 a settled meter floors at, and that update can land *after* the first
  frames. Both consumers already treat it as silence: MicLiveness's
  `!(power > floor)` spelling counts an out-of-range reading as not-live, and
  linearLevel floors it. This also settles the "silenceFloorDB was calibrated
  on the retired meter, re-verify on hardware" caveat from the backend move:
  -115 dBFS sits correctly between the sentinel and a live AirPods mic.

Both are now documented where the values are read, and the recorder test
polls for frames and power instead of sleeping a fixed 500 ms — that sleep sat
~10 ms from the AirPods first-frame time and would have flaked on a cold link.

check.sh green: 628 tests, 5 live tests on AirPods (serialized), coverage
89.16%, both sanitizers, periphery, app build, check-invariants --self-test.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

`record()` runs `AVCaptureSession.startRunning()`, which blocks for as long as
the hardware takes to open — ~180 ms on the built-in mic, ~600 ms on a USB
interface. Called inline from the actor it blocked `MicCapture` for that whole
window. Measured: a teardown arriving during the open waited 578 ms on a 635 ms
open. It also parked a cooperative-pool thread on a blocking call for the
duration — the same pool the context capture that deliberately overlaps the
bring-up and the transcriber's connection warm-up are running on, and starving
that pool is how covering the retired backend in CI deadlocked the entire test
run.

`record()` is now async and hops to a dedicated serial sessionQueue on the
recorder, so the open suspends the press instead of blocking anything. The same
teardown now takes 24 µs. A DispatchQueue rather than a detached Task on
purpose: the point is to park a Dispatch thread instead of a cooperative one.
It is also deliberately not the delegate queue — blocking that for the length
of an open would stall the very frames the liveness gate then waits for.

Scope of the win, stated honestly: through DictationSession this is latent
rather than user-visible. Its serial command queue already runs release and
cancel only after the press turn completes, and cancel() on `.connecting`
claims `.cancelled` synchronously without touching the mic, so Escape already
answered the UI immediately. What was actually blocked was the teardown, and
any host calling this public actor without serializing its own commands.

stopRunning() stays inline: 19–41 ms against the open's ~600 isn't worth
another suspension point on the release path the transcript waits behind, and
it cannot race the queue — every caller runs on a recorder whose record() has
already resumed.

The new suspension moves the teardown snapshot: stopGeneration is read before
the open rather than before the liveness wait, and checked at both ends, so a
stop or cancel landing while the input is coming up wins and the recorder is
torn down instead of installed. Without that, a press could install a live
recorder into a session whose caller had already been told the stop was clean.

MicCaptureBringUpTests pins the property. It calibrates against the real
device and skips its own assertion when the input opens too fast for the
window to be observable (AirPods open in ~100 ms), with
BLURT_LIVE_AUDIO_INPUT_UID to point it at a slower input — which is how the
USB case was covered on a machine whose default input is Bluetooth.

check.sh green: 628 tests, 6 live tests, coverage 89.09%, thread and address
sanitizers, periphery, app build.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Four review angles (reuse, simplification, efficiency, altitude) over
main...HEAD; findings deduped and applied. Two agents measured rather than
guessed, which changed two of my own numbers and caught one false comment.

Engine:

- start() had four hand-copied `recorder.stopAndDiscard()` exits and two
  verbatim copies of the abandonment test. The teardown is now one
  `defer { if !installed { … } }`, so a future suspension point inherits it and
  the failure mode of forgetting one — a live session with no owner, hot input
  indicator — can't come back. The two abandonment checks keep their distinct
  positions and log lines; only the duplicated bodies went.
- resolveInput did two device lookups of the same device per press to ask one
  question. AudioInputDevices.transportType(forUID:) now answers both: it
  returns nil exactly when no connected device carries the pin, since a
  transport read can't fail for a device that exists. isConnected is deleted,
  and CaptureSessionRecorder resolves its pin through the same
  AudioInputDevices.device(forUID:) — the two layers had drifted, the recorder's
  spelling missing the isConnected guard, so a device that had just gone away
  could be attached at one layer and called missing at the other.
- The session *build* joins the open off-actor. This was the /simplify finding I
  first skipped, on the grounds that folding build into "make and start" would
  destroy the live test's ability to assert that building leaves the mic closed.
  Hopping it separately keeps both steps observable: make() and record() are
  distinct async entry points on one static controlQueue (also now serializing
  session control across recorders, per AVFoundation's guidance). The slimmed
  bring-up test is what caught this — with its calibration probe gone, the
  teardown measured 100 ms instead of 24 µs, all of it the inline build.
- warmUp() read the full press-time input resolution to use one field of it,
  which spent two device lookups on a value the recorder re-resolves and could
  log "pinned microphone not connected" at launch, where nothing is recording.
  It reads MicDeviceSelection.pinnedUID now.
- activeTransportType stored a raw transport whose only use was deriving a
  Duration, and was never cleared, so a stop with no capture computed a linger
  from the previous one. It stores the Duration, cleared on detach — which also
  removes stop()'s read-before-the-suspension caveat.
- logName was derivable state on the hardware class, spelling a string for a
  caller that held the pin. Dropped; MicCapture logs the device instead.
- The upload geometry was six literals in a coverage-excluded file, and this
  branch had deleted its only covered assertion along with decodePCM. Channels
  and bit depth now come from SyncSTTLimits beside the byte math they must agree
  with, and MicCaptureFormatTests pins the link — a comment I wrote last commit
  claimed that test existed, and a reviewer caught that it didn't.

Tests:

- The BLURT_LIVE_AUDIO_TESTS gate was three copies of one condition and message;
  it and the .liveAudio tag now live in LiveAudioSupport.swift.
- MicCaptureBringUpTests dropped ~40 lines of calibration machinery, an
  undocumented env var, and a print-and-return that made it silently vacuous on
  any fast input. It asserts an absolute budget (10 ms against a measured 24 µs)
  which holds on every device, warms first the way the app does so it measures
  the property rather than first-touch cost, and now also asserts the press
  throws CancellationError — i.e. that the abandoned recorder was not installed.
- Three live suites open the same device while running in parallel, and one of
  them asserts on kAudioDevicePropertyDeviceIsRunningSomewhere, which answers
  for the device rather than for our client. It failed that way twice out of
  two. LiveAudioDevice.acquire()/release() serializes them; three consecutive
  runs green.

App:

- MicrophoneStepView moved to its own file (its stated reason for living inside
  SoundStepView — keeping the generated project unchanged — doesn't hold, since
  project.yml adds sources by directory; xcodegen regenerated).
- The picker binds MicDeviceSelection rather than the raw String, so
  ""-means-system is spelled once in the engine instead of again in a .tag("").
- Device enumeration moved off the main actor. It is a process's first touch of
  the capture stack when Settings opens before any dictation — measured 150–500
  ms cold — and it ran inline in onAppear while the window was laid out.

Prose made stale by this branch, including three files outside it: the
swift6-concurrency-reviewer subagent still told reviewers that AVAudioRecorder
was the deliberate backend, so it would have defended a backend this PR deleted
and flagged CaptureSessionRecorder as the violation; README.md's module map said
the same; MicCapture+Meter, DictationSession (twice) and a test still explained
themselves in terms of a disk read-back that no longer happens.

Skipped, with reasons: re-adding an injected recorder seam so the bring-up logic
is testable without hardware (a design decision that reverses 477efef, not a
cleanup — raising it separately); reading the transport off the recorder's
attached device (closes a narrow resolve→build race but moves the fallback
policy call into the recorder); warming the mic when permission is granted (new
behavior); a per-buffer allocation and a meter lookup both measured too cheap to
matter (0.035% of a core, 30 µs/s).

check.sh green: 630 tests, 6 live tests on real hardware, coverage 88.92%, both
sanitizers, periphery, app build, invariants --self-test.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

`.claude/agents/swift6-concurrency-reviewer.md` told reviewers that cleanup
"rides in the Sync STT `prompt`" — briefing a subagent that a field exists which
AGENTS.md and the project-guardrails skill both forbid reintroducing, and which
`ConversationContext.swift:30` says outright was replaced. Cleanup rides the
`llm` block's `instruction` (`CleanupInstruction`); the steering field is
`config.conversation_context`.

Missed in fb67c86, which corrected the AVAudioRecorder bullet three lines above
it in the same block. Caught by a reviewer reading the file afterwards.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…sion

`meteredPowerDB()` read `connection.audioChannels.first`, and `audioChannels`
describes the *device's* channels, not the mono the data output converts to.
Measured on this machine: a stereo interface, an aggregate and two virtual
devices all report audioChannels=2 against outputChannels=1, and a channel
carrying nothing reads -758 dBFS — far below silenceFloorDB (-115).

So on any device whose microphone sits on input 2 — a 2-in interface with the
mic in the second socket, or an aggregate whose first sub-device is silent — the
gate metered a silent channel while the recorded mono had full signal: the
liveness wait never confirmed, and the press failed CLOSED with "The microphone
didn't start." on a mic that records perfectly. The retired
AVAudioRecorder.averagePower(forChannel: 0) metered the recorded mono downmix,
so channel 0 was the whole picture there; this was a behavior change that rode
inside the backend swap unnoticed, through a green check.sh both times.

Now a max over all channels. It slightly over-reads the true downmix (one loud
channel of two averages quieter once mixed), which is the harmless direction for
a floor probe and for meter bars.

Also from the same review pass:

- start()'s third suspension had no abandonment check. Moving the session build
  off-actor added it without one, which is precisely the drift the last commit
  predicted, so the guard is now one throwing `checkStillWanted(since:stage:)`
  called after each suspension — log line and throw included, so a fourth
  suspension point adds one line and cannot get the handling wrong.
- The mic picker showed "Disconnected microphone" for the 150-500 ms of a cold
  device read, because the empty initial array read as "the pin is gone". A
  `devicesLoaded` flag separates "not read yet" from "read, and empty" (a flag
  rather than an optional array: `discouraged_optional_collection` is opted into
  repo-wide, and check.sh caught it).
- A refused input or output logged nothing, leaving "no usable input device" or a
  fail-closed timeout with no explanation.
- Two stale references of my own: a doc naming `sessionQueue` after the rename to
  `controlQueue`, and AGENTS.md still describing the bring-up test as calibrating
  and skipping itself after fb67c86 removed both. That is the second false doc
  claim I've introduced in this branch and the second caught by a reviewer.

Accepted rather than fixed: the bring-up test's fixed 30 ms sleep. The safe
window is roughly [1 ms, 80 ms] — the press must have started, and must not have
completed — since the fastest open measured here is ~80 ms and the liveness gate
then waits on a meter that lags the first frames. 30 ms sits mid-window; moving
it to ~2 ms as suggested would trade the upper edge for the lower one. The
assumption is now named in the test.

Worth recording: both serious findings here live in files the coverage gate
excludes, reachable only through code with no injectable seam, and check.sh was
green through both. That is the concrete argument for the deferred recorder-seam
decision — a stub returning a fixed meteredPowerDB() would have caught the first,
and a stub whose make() suspends on a test-held continuation the second.

check.sh green: 630 tests, 6 live tests on real hardware, coverage 88.92%, both
sanitizers, swiftlint --strict, periphery, app build.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The old comment blamed `#expect(throws:)` not being able to capture an
`async let`, which isn't the reason — the test cancels the press and then
inspects how it ended, so the handle has to outlive the statement.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>